Method and system of securely enforcing a computer policy

ABSTRACT

A method and system for securely enforcing a computer policy uses a secure computer resource ( 102 ) which includes both data ( 106 ) and policy rules ( 110 ) to be applied. The resource also includes a control set ( 108 ) which specifies the operations that are permitted on the resource, and the criteria under which permission will be given. An external agent ( 104 ) wishing to use the resource sends a request to a secure processor ( 100 ), which uses an access processor ( 120 ) to confirm that the operation is approved. As the operation proceeds, an operation processor ( 118 ) checks against a list of conditions ( 124 ) and stops when one occurs. If the condition corresponds to a trigger within the policy, control is passed to a policy processor ( 122 ) which securely executes a corresponding method, also defined within the policy. The resource is digitally signed by its owner who can therefore be sure that the embedded policy will always be followed when an approved operation is applied to the resource by an approved user.

The present invention relates to the secure enforcement of computerpolicies, and particularly although not exclusively to methods andsystems which enable enforcement by means of delegated trust.

Many secure computer systems, especially but not only in the banking andfinancial services industries, make use of automated policies controlledby a “policy enforcer” or auditor. For example, where cryptographic keysare in use, the policy might specify that whenever the system attemptsto use an out of date key an entry is written to a secure log for latermanual checking by the auditor. A difficulty with this approach is thatwhere a problem occurs it needs to be manually tracked back to itsultimate source after the event. If for example it is found that thesystem has incorrectly used an invalid key, but has not for some reasonwritten an entry into the log, a lengthy investigation may be required,including an after-the-event check that the routine that writes to thelog was not disabled or tampered with by an attacker.

More generally, current high-security processes normally use manualaudit to measure conformance with policies after the event. This is bothexpensive and potentially unreliable. Such automated systems as existneed to be performed on specialist secured computers if they are to beconsidered secure.

It is an object of the invention at least to alleviate these problems ofthe prior art.

The invention stems from a development of the concepts disclosed inWO-A-0163385, in the name of the present applicant, which describes amethod of selectively controlling access to a computer resource by meansof a cryptographic key associated with the resource. The presentinvention is concerned not just with the controlling of access, but theenforced operation of procedures which the auditor confirms in advanceare “safe”. In particular, the invention allows a user to define apolicy or method which the auditor accepts as being safe; that is thenapproved and digitally signed by the auditor. The user then allows thatapproved policy to run in a secure manner. Should an error be noted at alater stage, the auditor now no longer has to check whether the policyis operating correctly or whether it may have been subverted by anattacker, since that check will now have been done automatically by thesystem, whenever the policy was run. The fact that the policy has run atall confirms to the auditor that it cannot have been tampered witheither before being run or during operation.

According to a first aspect of the present invention there is provided amethod of securely enforcing a computer policy comprising:

-   -   (a) providing a secure computer resource including:        -   (i) data        -   (ii) a policy to be applied to the resource, the policy            including a trigger and an associated computer method;    -   (b) executing an operation on the data while watching for an        occurrence of the trigger; and    -   (c) when the trigger occurs, securely enforcing execution of the        computer method.

According to a second aspect of the invention there is provided a systemof securely enforcing a computer policy comprising:

-   -   (a) a secure computer resource including:        -   (i) data        -   (ii) a policy to be applied to the resource, the policy            including a trigger and an associated computer method;    -   (b) an operation processor for executing an operation on the        data while watching for an occurrence of the trigger; and    -   (c) a policy processor for securely enforcing execution of the        computer method when the trigger occurs.

This invention allows pre-defined policies to automate the policy auditfunction while allowing high levels of security, thereby giving costefficiencies and allowing higher scalability than may be feasible withmanual techniques. It further provides general purpose, and thereforeflexible automated and secure processes. In addition, it allows clearand flexible demarcation between highly secure parts of a process (i.e.in policies), for less secure programs, which allows for incrementalautomation of high security parts of current processes.

The invention may be carried into practice in a number of ways and onespecific embodiment will now be described, by way of example, withreference to the accompanying drawings, in which:

FIG. 1 is a diagrammatic representation of a preferred embodiment of theinvention;

FIG. 2 is a diagrammatic representation of the access processor in FIG.1; and

FIG. 3 is a diagrammatic representation of the resource in anotherembodiment

In the preferred embodiment of FIG. 1, the system comprises a secureprocessor (typically a secure hardware module) 100 that performs anoperation on a resource 102 when requested by an external agent 104.

The resource 102 includes data 106, the content of which depends uponthe type of resource. If the resource relates to a cryptographic key,for example, the data will include the key value; if the resourcerelates to database record, the data includes the set of values thatcorrespond to the fields in the record; and if the resource relates to atime stamp, the data defines the time. Also contained within theresource 102 is a control set 108, a policy list 110 and a signature set112, details of which will now be described.

The control set 108 specifies the set of conditions that the creator orowner of the resource (who will be called for the sake of simplicity the“owner”) has specified that must apply before the secure processor 100is authorised to perform each operation with the data 106. Morespecifically, the control set comprises a set of two-part entries, withthe first part of each pair defining an operation and the seconddefining a criterion. The operation identifies an inherent, pre-definedfunction that the secure processor 100 may do on the data, for examplereading, writing, encrypting, signing and so on. The criterion defineswhat must be true before the secure processor is permitted to performthe corresponding operation.

The policy list 110 specifies a set of activities that the secureprocessor must automatically invoke as it carries out each operationdefined by the control set 108 on the data. The policy list 110 is alist of triggers and corresponding methods (such as a set ofinstructions in a program) that the secure processor is to perform whenthe respective trigger is activated. Each trigger identifies a specificcondition in a list 124 that will be watched for when the secureprocessor carries out the operation on the data. Exemplary conditionsmight include “before starting the operation”, “after completing theoperation” and so on. Each condition may be viewed as a pair, namely{Operation, State}. Each trigger corresponds to the pair {Operation,Condition}.

For example, consider a resource which represents an encryption key,with control set entries:

-   {Op2=encrypt; Crit 2.1=‘before starting’; keyId 2.1=10003}-   {Op2=encrypt; Crit 2.2=‘before finishing’; keyId 2.2=10004}

The corresponding operation entry for an operation “encrypt” is:

-   {encrypt, {before starting); after encrypting a block; after    finishing}

The policy list contains: {policy 1; policy 2, . . . }, i.e.

-   {Trig 1={encrypt, before starting}; method 1}-   {Trig 2={encrypt, before finishing}; method 2}

Method 1 checks whether the encrypting key is in service, for example,by checking that its expiry date is in the future. If the key hasexpired, it ‘makes_new_key’—creates a new key and stores the previousone in some archive. Policy 1 is signed by the owner of signing keyId1000, who may be responsible for day-to-day key operational management.

Method 2 keeps a total of the amount of data encrypted with theencryption key and ‘makes_new_key’. Policy 2 is signed by keyId 10004,which is owned by the security manager, who sets high level operationalpolicy.

The conditions for the operation encrypt (where the resource representsa cryptographic key) could be the set: {before starting, afterencrypting a block, after completing all the encryption}etc, and mayinclude all the relevant states in all possible encryption operations.

A given control set, for a given resource, references only thoseconditions that are relevant to it. Op 2 might for instance haveCriterion 2.1=‘before starting’; and criterion 2.2=‘after completing’,only; and not reference ‘after encrypting a block’, since it is notrelevant for that specific resource.

The policy list must contain at least entries that correspond to all thecriteria in the corresponding control set.

However, the policy list will often contain a set of policies for allthe conditions in all the operations, since typically the policy listswill be unified over many resources and this unification provides aneconomy of scale in policy management.

Of course, a resource's policy list must contain policy entries at leastfor all criteria on the corresponding control set.

In many cases the condition list will be embedded in the implementationof the operation processor, so, therefore, will not be distinct orexternal data. For example, if the resource represents ‘secure time’,the secure processor hardware and firmware will implicitly define theoperations {read, modify}, and may explicitly implement the conditions:{before starting, after completing}.

However, where the resource represents more abstract business data, theoperation list may be explicit and distinct from the secure processor;the processor may load and perhaps even manipulate it dynamically. Forexample, if the operation list is associated with a work-flow process,one may want to be able to upgrade the system periodically to load newoperations into the secure processor.

Clearly it is not necessary to sign the condition list when it isembedded within the secure processor; but if external, it will besigned.

Associated with each element of the policy list 110 is a signature set112, comprising a set of one or more digital signatures. Each of thesedigital signatures is made with a signing key 114 having a key Id 116.

In this embodiment, the signature set is a digital signature with asigning key thus: Sign({trigger, method}, signing key), where ‘a{a, b, .. . }’ means concatenate ‘a’ and ‘b’, etc. although specificimplementations may choose to concatenate other data in the signature.

The key ID is cryptographically derived from a {signing, verifying}key-pair, in such a way that the secrecy of [at least] the signing keyis not compromised.

For example, the key ID could be:

-   ‘hash({signing key, verifying key})’-   where ‘hash( )’ is a one-way digest function with the property that    it is very difficult to deduce ‘a’, given ‘hash(a); and ‘{a, b}’    means ‘a’ concatenated with ‘b’.

A criterion references one or more key Ids, thereby associating to asigning key, and corresponding verifying key, without compromising theirconfidentiality.

The functions of secure processor 100 are performed by an operationprocessor 118, an access processor 120 and a policy processor 122.

The operation processor 118 executes the steps of the operation that hasbeen requested by the agent 104. As the operation proceeds, theprocessor watches for the existence of any condition taken from acondition list 124, the contents of this list being dependent upon theoperation being performed. The entries in this condition list correspondwith the triggers within the policy list 110 of the resource.

When the operation processor reaches a condition within the conditionlist 124, it stops and passes control to the access processor 120. Thischecks the resource to ensure that the relevant policies satisfy theassociated criteria within the control set 108. If so, control is thenpassed to the policy processor 122. This is done by means of a verifyingkey 124 which corresponds to the signing key 114 of the signature set112 within the resource. The verifying key 124 is identified by means ofa key Id 116′ which is the same as the key Id 116 of the signing key114.

The purpose of verifying key, of course, is to enable the accessprocessor 120 to verify a signature which has purportedly been made withthe signing key 114. Accordingly, the secure processor 100 may execute aparticular policy during a given operation on a resource if and only ifthat policy contains a signature within its signature set 112 that wassigned by the signing key 114 that the key Id 116′ identifies.

The policy processor executes the appropriate method from the policylist 110, depending upon which condition has triggered, and then returnscontrol back to the operation processor.

By this mechanism, the owner of the signing key 114 (which could be aperson or a machine) can:

-   (a) delegate trust to a signed policy (as represented by the    combination of the policy list 110 and the signature set 112);-   (b) bind that trust to an individual resource 102, thereby ensuring    that a policy is run only against appropriate resources; and-   (c) revoke the trust in (b) by ensuring the removal of the verifying    Key 124

A signature by the Owner of the signing key can thus be used to conveyone or more of these properties:

-   ‘proof of origin’-   that the owner of signing key originated the associated policy or    policy list;-   ‘integrity’-   that the policy, or policy list, is unchanged from when the owner    signed it; and-   ‘delegation’-   that the owner authorises in advance the execution of the method in    the associated policy (or methods in the associated policies in the    policy list).

In that way, the use to which the data 106 may be put can be predefinedand controlled in advance by the owner of the resource or the auditor.Since the policies always stay with the resource throughout its life, noadditional external or gatekeeper control is required when the resourceis run: the resource effectively polices itself.

The detailed operation of the described system will now be set out, withfurther reference to FIG. 1 and also to FIG. 2. In order that theoperational flow may be easy understood, reference should be made to theparagraph numbers below which correspond with the similarly numberedarrows in the drawings.

-   1. To start, the secure processor 100 receives an instruction from    an external agent 104 to perform Operation 1 on a given resource    102, which it passes to the operation processor 118.-   2. The operation processor notes the list 124 of conditions that    correspond to Operation 1. It executes Operation 1, step by step,    and stops at the first condition in the list, namely Condition 1.-   3. The operation processor then passes control to the access    processor 120.-   4. The access processor requests the control set 108 from the    resource, and loads all the operation/criteria pairs that correspond    to Operation 1. It also loads all the associated key Ids 126 that    each criterion references. In the example shown, the access    processor loads criterion 1.1 and key Id 1 both of which are    associated with Operation 1.-   5. The access processor loads from the policy list 110 all the    policies that have a trigger equal to Condition 1, along with the    associated signature set 112. In this case, signature set 1 is    loaded (these signatures having previously been prepared by means of    the signing key 1).-   6. The access processor loads all of the verifying keys 124 that are    associated with the loaded key Ids. Since signature set 1 is    associated with key Id 1, the access processor simply loads the    corresponding verifying key 1.-   7. Then, for each policy which has been loaded into the access    processor, the following steps occur (refer to FIG. 2):    -   7.1 the access processor matches key Ids. Specifically, it        compares the key Id 126 corresponding Criteria 1.1 with the key        Id 116 from the loaded signature set 112.    -   7.2 If the match succeeds for at least one key Id, processing        continues at step 7.3; otherwise an error is signalled and the        procedure ends.    -   7.3 Next, the access processor verifies the signature.        Specifically, it verifies the signature from the policy that        matches key Id 1, namely signature 1.1, with the corresponding        verifying key 1.    -   7.4 If the verification succeeds, processing continues to step        8; otherwise, an error is signalled and the process stops.-   8. Once all of the tests within the access processor have been    completed successfully, control passes to the policy processor 122.    The policy processor executes the corresponding method in the policy    list 110 that has been triggered; in this case, method 1.-   9. Once the policy processor has executed the required method,    control is returned to the operation processor 118 which continues    to step through Operation 1 until Condition 2 is reached. The entire    cycle repeats until the operation is complete.-   10. Finally, the processor returns control to the agent 104.

Where there is no access to the resource except via the secureprocessor, there is no need for the resource itself to be furtherprotected. But where direct access is permitted, the response (or atleast the data within it) may be cryptographically protected and/ordigitally signed, as shown at 150 in FIG. 1. Where the condition lists124 are separate from the resource, they may also be encrypted and/orsigned, as shown at 160 in FIG. 1. The resource and/or the conditionlist may be signed multiple time—i.e. signature A and signature B mayrepresent signature sets. Where the resource and/or the condition listis or are signed and/or encrypted, the operations processor and theaccess processor should respectively verify the signature and/or decryptwhen reading the data (see the arrows 2 and 4 in FIG. 1). Such anapproach allows the owner to protect both integrity and proof of origin,as well as confidentiality (if encryption is used). It will beunderstood, of course, that the signing key(s) 150, 160 used to sign thecondition lists 124 and/or the resource need not be the same as thosekeys 114 used to make the signatures set 112 that is associated with apolicy.

All of the signatures previously mentioned may use either symmetric orasymmetric keys.

In yet another embodiment, shown in FIG. 3, the resource is splitbetween a data portion 310 and a policy portion 320. The former includesdata 106, control set 108, and key ids 126, while the latter includesthe policy list 110 and the signature set 112. Where the resource may beaccessed other than via the secure processor 100, the two separate partsmay be digitally signed by signatures or signature sets 150, 150; whereconfidentiality is important, the two parts may also be encrypted.

The data portion 310 is associated with the policy portion 320 in anyconvenient way, for example by ensuring that at least one of the signingkeys in Sig. B₁ is the same as at least one of the keys in Sig. B₂. Whenthe access processor 120 loads the data and policy portions, as shown bythe arrows 4, 5, the system confirms that this is the case.

Where encryption is used, the signature is taken over the encrypteddata, i.e.

Sign(Encrypt(Data, Encryption Key, Signing Key)).

As before, the signing keys may be symmetric or asymmetric.

The method and operation of the present invention is applicable to awide variety of types of resource 102 and associated data 106. However,there are three particular examples which merit special mention, namelycryptography, database records, and time servers. These are addressedseparately below.

Where the invention is used in a cryptographic setting, the resource mayrepresent a cryptographic key. The data 106 will then generally containcryptographic material that determines the particular key, for examplethe 56-bits of a given Data Encryption Standard (DES) key, or largeintegers for an RSA public or private key. The data may also containother information, for example creation date, destruction date, “don'tuse after” date and so on. Operations that may be defined in respect ofthe data will include encrypt/decrypt, sign/verify, load, create, deleteand so on.

The policy associated with the encrypt or load operations might includea method that checks the “don't use after” date, and signals to anexternal system if the key is being used inappropriately. The createoperation could result in the invocation of a method that populates thedata which a new key that is generated with parameters which are definedwithin the method.

In the database example, the resource may represent a relationaldatabase record, with the data containing the values of all of thefields that constitute that record. Operations may typically includeread, create (write) modify and delete. Other high-level operationscould equally well be envisaged, for example the running of a SQLscript.

In the final example, the resource may represent time as supplied by asecure clock. The data then contains the current time, with theoperations including such things as read and modify. A resource of thistype may be useful in for example a market trading system, in whichrules about when things can happen may be encapsulated in the resourcepolicies. Rules could also be set up to control and/or to record theordering of events in time.

In the specific embodiments so far described, a resource owner orauditor can reliably trust the way in which the resource is going to beused because the rules defining that trust—in other words thepolicies—are built into the resource itself. It is also anticipated,however, that more complex webs or chains of trust may be created by theuse of multiple signatures having multiple owners. For example, a singlepolicy may define multiple rules, each having separately-ownedsignatures. The resource itself would then decide who will next beallowed to authorise the next step. In this way, work-flows may be builtin. An example of this would be a document the entire life cycle ofwhich is to be specified in advance. The policy may define a chain ofusers who are authorised to review and to modify the document one byone. After the first person has made any required amendments, the policyautomatically encrypts the document using the public key of the secondperson in the list; once the second person has made amendments thedocument is automatically re-encrypted with the public key of the thirdperson on the list, and so on.

Multiply-owned signatures may also be used to require multipleauthorisations. An example of such a situation might be the records of aparticular house for sale. Those records may be protected by the houseowner and may be stored on the individual databases of a number ofdifferent estate agents only if the owner gives permission on anagent-by-agent basis. But if an aggregator service were to wish to takedata from a particular agent, for display on an aggregation web site,that data would require authorisation from the agent. The data for anindividual house might therefore be defined by an individualhouse-resource which is protected by two separate signing keys, thefirst owned by the house owner which authorises the data to be stored onthe agent's database, and the second owned by the estate agent whichauthorises that data to be used by the aggregator.

The system of the present invention may be embodied either in softwareor in hardware, or in a combination of the two. Typically, the secureprocessor 100 may be a hardware security module, either with separateindividual modules 118, 120, 122 within it, or alternativelycorresponding logically separate processes running as a computerprogram.

In some embodiments, only the secure portions of the operation processor118 need be contained within a secure processor module: those portionsin the operation which are not required to be secure may be outside thesecure boundary. In an alternative. embodiment, the operation processor118, the access processor 120 and the policy processor 122 may compriseseparate secure physical modules, or separate logical processes, whichcommunicate with each other via one or more secure channels.

In one arrangement, the policy processor 122 may take the form of asecure module on a motherboard of a client machine (not shown). Thatenables the individual user to securely execute the required methodswithout needing to access a central server.

Alternatively, a proxy model may be used, in which a small secure box ona client machine provides sufficient functionality to bootstrap a secureconnection with a central policy processor on the server which actuallycarries out the work.

Where the policy processor is client-based, it could also take the formof a SIM card on a mobile telephone, or a card which fits into anexpansion slot within a desktop or laptop computer.

1. A method of securely enforcing a computer policy comprising: (a)providing a secure computer resource including: (iii) data (iv) a policyto be applied to the resource, the policy including a trigger and anassociated computer method; (b) executing an operation on the data whilewatching for an occurrence of the trigger; and (c) when the triggeroccurs, securely enforcing execution of the computer method.
 2. A methodas claimed in claim 1 in which the resource further includes a controlset specifying: (a) operations that a user may wish to perform on theresource; and (b) corresponding criteria defining the circumstancesunder which each respective operation is permitted.
 3. A method asclaimed in claim 1 in which the policy includes a signature, anoperation being permitted to run only if both its respective criterionis satisfied and the signature is approved.
 4. A method as claimed inclaim 3 in which the signature is approved if a key Id indicative of asigning key used to create the signature matches a key Id of a verifyingkey associated with the signing key.
 5. A method as claimed in claim 1in which the policy includes a signature bound to the said trigger andcomputer method, the trigger and computer method being verified againstthe signature before the computer method runs.
 6. A method as claimed inclaim 1 in which the trigger is associated with a conditionrepresentative of a program state or an event associated with a programstate.
 7. A method as claimed in claim 1 in which the operation isexecuted while watching for an occurrence of one or more conditionswithin an operation condition set and, when a said condition occurs,verifying the policy before executing the computer method.
 8. A methodas claimed in claim 7 in which the verification is carried out by asecure access processor which passes control, if the policy is verified,to a secure policy processor to execute the computer method.
 9. A methodas claimed in claim 2 including controlling a user's access to the datain dependence upon the control set.
 10. A method as claimed in claim 1in which the operation on the data is carried out securely.
 11. A methodas claimed in claim 1 in which a first part of the operation on the datais executed securely, with a second part being executed non-securely.12. A method as claimed in claim 1 in which the policy includes aplurality of triggers and associated computer methods.
 13. A method asclaimed in claim 1 in which the resource includes a plurality ofpolicies.
 14. A method as claimed in claim 13 in which the resourceincludes a plurality of signature sets corresponding to the saidplurality of policies.
 15. A method as claimed in claim 3 wherein aplurality of signatures associated with a single criteria, an operationbeing permitted to run only if all of the associated signatures areapproved.
 16. A method as claimed in claim 2 in which the control setincludes a plurality of operations and corresponding criteria, eachoperation/criteria pair being bound to one or more of a plurality ofsignatures within the policy, whereby control of the resource is sharedbetween respective signature owners.
 17. A system of securely enforcinga computer policy comprising: (a) a secure computer resource including:(iii) data (iv) a policy to be applied to the resource, the policyincluding a trigger and an associated computer method; (b) an operationprocessor for executing an operation on the data while watching for anoccurrence of the trigger; and (c) a policy processor for securelyenforcing execution of the computer method when the trigger occurs. 18.A system as claimed in claim 17 in which the operation processor and thepolicy processor are contained within a secure hardware module.
 19. Asystem as claimed in claim 17 in which the operation processor comprisesa secure portion and an insecure portion.
 20. A system as claimed inclaim 17 including a secure access processor which controls access tothe policy processor from the operation processor.
 21. A system as inclaim 17, wherein the operation processor and the policy processor arecontained within a secure hardware module; and a secure accessprocessor, which controls access to the policy processor from theoperation processor is contained within the secure hardware module. 22.A system as claimed in claim 17 in which the operation processor and thepolicy processor are contained with respective hardware modules, andcommunicate with each other via a secure channel.
 23. A system asclaimed in claim 22 including a secure access processor which controlsaccess to the policy processor from the operation processor.
 24. Asystem as claimed in claim 23 in which the access processor is containedwithin a secure hardware module which communicates with the operationprocessor and the policy processor via secure channels.
 25. A method asclaimed in claim 1 which the resource is secured by encrypting it.
 26. Amethod as claimed in claim 6 in which the condition is stored within thepolicy.
 27. A method as claimed in claim 6 in which the condition isstored separately from the policy.
 28. A method as claimed in claim 27in which the condition is encrypted.
 29. A method as claimed in claim 1in which the resource is digitally signed.
 30. A method as claimed inclaim 1, in which the condition is digitally signed.
 31. A method asclaimed in claim 1, in which the resource is split into a first portionincluding the data and a second portion including the policy, the firstand second portions being digitally signed by a common signature.
 32. Asystem as claimed in claim 17 in which the response is signed by adigital signature, and in which the operation processor or policyprocessor verifies the signature prior to the said operation beingcarried out on the data.
 33. A system as claimed in claim 17 in whichthe response is encrypted, and in which the operation processor orpolicy processor decrypts the response prior to the said operation beingcarried out on the data.